1. Statement of the Technical Field
The present invention relates to the field of virtual private networking and more particularly to a method and system for allowing an engineered virtual private networking solution through the use of a tandem routing device as a virtual hub in a logical hub and spoke network topology.
2. Description of the Related Art
A virtual private network (“VPN”) allows a subscriber to use a shared networking infrastructure to provide access among the subscriber's networked devices in a manner which preserves the security and integrity of the data transmitted between the networked devices. In other words, a VPN provide remote offices or individual users for a subscribing entity with secure access to their organization's network, even though the underlying transport network is shared by many organizations. Privacy is maintained via security procedures and tunneling protocols. In effect, the tunneling protocols encapsulate data at the sending end and decapsulate it at the receiving end, send the data through a “tunnel” that cannot be “entered” by data that is not properly encapsulated. The data packets are received at a provider network entry point at a provider edge (“PE”) device, encapsulated and routed through the service provider's network and decapsulated at a far end PE device. The PE's send and receive data to/from customer edge (“CE”) devices such as customer routers. CE devices provide access to/from customer networks and devices. In essence, the provider network acts as the network cloud used to transport data from CE device to CE device.
While simple in principle, VPN service providers face myriad problems when trying to implement and support customer VPNs, particularly in the area of designing the network to meet the committed information rate (“CIR”) typically guaranteed to subscribers. CIR is a bandwidth, typically expressed in bits per second, associated with a logical connection between CE devices and/or access to the provider network such that the service provider provides some level of assurance that data delivered to the PE at or below the CIR will actually be accepted by the PE. Subscribers are typically allowed to send traffic at a rate above the CIR, but without any assurance that such data will be accepted and or delivered to the destination CE device.
Current transmission control protocol/internet protocol (“TCP/IP”)-based VPNs suffer from a number of drawbacks which lead to inefficient and expensive implementations. This typically results from the inability of service providers to engineer the underlying network supporting the VPNs. Standards such as Request for Comment (“RFC”) 2547 attempt to set grounds rules for the provisioning of VPNs to allow subscribers to outsource their network backbone services to service providers. For example, RFC 2547, the entirety of which is incorporated by reference herein, sets out a method, elements and functions under which a service provider can use a TCP/IP backbone network to provide VPN services. RFC 2547 describes an arrangement under which an exterior gateway protocol, such as the border gateway protocol (“BGP”) is used to distribute routes throughout the backbone network and multiprotocol label switching (“MPLS”) is used to forward the customer's data packets across the backbone.
RFC 2547-based implementations take a many-many approach and use BGP flooding to obtain a linear provisioning model at the service layer (of the open systems interconnection (“OSI”) model). RFC 2547-based implementations replicate the route table and forwarding table to create a virtual mesh of the CE devices and depend on an underlying connectionless network to provide a logical mesh of the PE devices. The use of a connectionless “cloud” to mesh the PE devices that is completely decoupled from the contracted service connecting CE devices is inefficient, can lead to outages and over-building of the backbone network because the operation of the underlying connectionless cloud is completely decoupled from the contract load (amount of customer data) or adds moves and changes to customer sites or customer behavior. With current RFC 2547-based implementations, the impact of customer behavior on network loading is not constrained and changes in customer behavior or addition of new customers can have unexpected effects on overall network performance. The present mode of operation for RFC 2547 based networks is purely reactive. Service providers watch traffic and utilization reports, then react to link oversubscription or underutilization by fiddling with routes, adding/deleting logical bandwidth from the links between PE devices and/or adding physical capacity to the backbone network. This is not necessarily coupled to customer change requests and therefore may not have any associated revenue as it merely may be a change in customer traffic patterns that are within contractual boundaries. It is desirable to have a backbone design and provisioning method and resultant service provider backbone network in which capacity is added as needed instead of adding too much capacity when not needed or once service problems have manifested themselves. A deterministic coupling between backbone engineering/capacity and customer adds, moves and changes is very desirable.
Service provider implementations, such as those described above with respect to RFC 2547, may be defined as point-to-cloud networks. These implementations disadvantageously (1) route traffic down the shortest weighted path and require the manual manipulation of routing algorithms to optimize network traffic distributions, (2) require operators to deal with “slosh”, i.e. bursty subscriber traffic which can result in insufficient bandwidth or too much bandwidth and (3) require engineered over-subscription (exacerbates “slosh” vulnerability to changes in subscriber behavior). In addition, trying to offer/manage a quality of service (“QoS”) feature as part of the service provider offering for a full mesh backbone is prohibitively expensive in terms of the signaling requirements and/or the amount of backbone bandwidth which must be made available.
It is therefore desirable to have a method and system to provide a VPN backbone which offers a simple topology and which is engineered such that capacity can be added as needed and which is deterministic such that service providers can easily and accurately determine what the backbone should look like in response to the provisioning of services, easily measure the quality of the service they offer and have appropriate coupling between services and inventory. It is further desirable to have a method and system in which artifacts of individual VPN's operational behavior such as the impact of moves, adds and changes, seamlessly integrates into service provider network operations and does not have undesirable downstream effects while constraining the effect of subsequent changes in customer behavior.
In addition, because backward compatibility is typically a concern of service providers as they move to implement and integrate newer technologies, it is desirable to have a system and method which is compatible with existing implementations, such as those based on RFC 2547.